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Title: Method and System for Processing Invoices 
Field of the Invention 

5 This invention relates to a system and method for 

facilitating online commerce over a public network such as 
the Internet or an interactive T.V. cable network. More 
particularly, this invention relates to a system and method 
for conducting online processing of an invoice including 
10 multi-stage invoice handling capabilities. 

Background of the Invention 

Online commerce has experienced dramatic growth in 

15 recent years and this growth is expected to continue into 
the coming decades. Internet service providers are, more and 
more, connecting users to the Internet at no cost, thus 
eliminating barriers to an Internet connection. At the same 
time, merchants are increasingly developing sites on the 

20 World Wide Web (or simply "WWW" or "Web") that customers can 
access to order goods and/or services. It is now fairly 
common for a customer to browse a merchant's catalogue, 
select a product or service and place an order for the 
product/service all electronically over the Internet. 

25 Similarly, it is becoming increasingly common for merchants 
to allow payment of invoices electronically. Typically, the 
invoice is sent electronically to the customer via 
electronic mail or made available to the customer over a 
network by providing the customer with network access 

30 capability. 
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U.S. Patent 6, 128, 603 issued to Dent et al . on October 
3, 2000) describes a consumer-based system for analyzing, 
managing and paying electronic bill statements received from 
a biller. The biller electronically transmits a customized 
5 statement to a consumer 7 s computer terminal over the 
Internet. The biller' s electronic bill is presented to the 
consumer through a user interface. After reviewing the 
electronic bill the consumer can enter how much of the bill 
to pay, from which account to pay from, and the desired 
10 payment date. The entered information is then transmitted 
to the biller for processing. The contents of U.S. Patent 
6,128,603 are incorporated herein by reference. 

Similarly, U.S. Patent 6,070,150, issued to Remington 
15 et al. on May 30, 2000, describes an electronic payment 
system in which a biller electronically transmits a bill to 
a consumer over the Internet. The bill may arrive at the 
consumer's terminal via email or a notification for the 
consumer to check a billing mailbox. The consumer receives 
20 the bill that can be displayed in the form of a user 
interface. After reviewing the bill the consumer is able to 
enter the amount to be paid, the date of payment and from 
which account the money can be taken. The system described 
in Remington et al. also includes the ability to let the 
25 consumer dispute an item in an invoice. The contents of U.S. 
Patent 6,070,150 are incorporated herein by reference. 

A deficiency with the above-described systems for the 
payment electronic of invoices is that they are ill suited 
30 to certain business-to-business environments. In a typical 
business setting, it is not uncommon for several people to 
be involved at different stages in the handling of an 
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invoice such as, for example, a division manager, a clerk in 
the accounts payable department and the manager of the 
accounts payable department. In these situations, the 
invoice is typically printed at the division manager's 
5 office, approved by the division manager and forwarded by 
internal mail (or e-mail) to the accounts payable department 
where one or more individuals authorize the payment to be 
made. This process is time consuming and often results in 
delays in the payment of an invoice. 

10 

Consequently there exists a need in the industry to 
provide an improved system and method for processing 
invoices that alleviates at least in part the deficiencies 
of prior art systems and methods. 

15 

Summary 

In accordance with a broad aspect, the invention 
provides a method for electronically presenting and granting 

20 payment of invoices. The method includes generating an 
invoice at a biller and making the invoice electronically 
available to a customer entity. A first user associated to 
the customer entity is enabled to approve the invoice and a 
second user associated to the customer entity is enabled to 

25 authorize payment of the invoice, the second user being 
distinct from the first user. A data element indicating that 
payment of the invoice has been approved is transmitted from 
the first user to the biller. Another data element 
indicating that payment of the invoice has been authorized 

30 is transmitted from the second user to the biller. The 
granting of payment of the invoice is detected at the biller 
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when payment of the invoice has been approved and 
authorized. 

An advantage of the present invention is that it allows 
5 a customer entity to obtain account information without 
interacting with a person at the biller' s location. 

Another advantage of the present invention is that it 
facilitates the involvement of several individuals in the 
10 handling of an invoice. 

Another advantage of the present invention is that it 
allows for at least two individuals to be consulted at 
different stages of the payment of an invoice such as at the 
15 approval stage and at the authorization stage. It will be 
readily appreciated that more than two stages may be present 
and more than two individuals may be involved in the 
handling of an invoice without detracting from the spirit of 
the invention. 

20 

In a specific implementation, the data element 
indicating that payment of the invoice has been approved and 
the data element indicating that payment of the invoice has 
been authorized are transmitted to the biller independently 
25 from one another. 

Advantageously, this provides the biller with 
information regarding the stage of the payment of the 
invoice. This is particularly advantageous and allows the 
30 accounts receivable department at a biller site to readily 
determine at which stage an unpaid invoice is being delayed 
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and to determine which person of the customer location to 
contact . 

In a non-limiting example of implementation, the second 
5 user associated to the customer entity is enabled to 
authorize payment of the invoice subsequent the data element 
indicating that payment of the invoice has been approved is 
received at the biller. 

10 Advantageously, this allows the order in which the 

stages of the invoice handling process to be effected in a 
desired order namely the invoice has to be approved prior to 
being authorized. 

15 The users associated with the customer entity may be 

resident in a same location, such as a single office or 
multiple offices in a same building, as well as may reside 
in geographically remote locations. For example, the first 
user may reside in New York, NY, USA while the second user 

20 may reside in Vancouver, B.C., Canada. The first user has 
payment approval privileges and the second user has payment 
authorization privileges. 

In a specific example of implementation, the invoice is 
25 electronically transmitted over a network. In a first non- 
limiting example of implementation, the invoice is 
transmitted via e-mail to the first and second users at the 
customer entity. In this implementation, the invoice is 
provided as a data structure including an approval field and 
30 an authorization field, the approval and authorization 
fields being modifiable by the first and second users 
respectively. In a non-limiting example, a field is provided 
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allowing the second user to provide payment remittance 
information credit card information, an authorization to 
debit a bank account, wire transfer information, direct 
deposit information or an indication that a check will be 
5 mailed. 

In a second specific example of implementation, the 
invoice is electronically transmitted over the Internet. In 
a non-limiting example of implementation, in order to view 

10 invoices and other account information, the users associated 
with the customer entity log on to a secure web-site using 
login names and associated passwords. The account 
information is displayed on a graphical user interface on 
the customer's computer terminal. Unpaid invoices are 

15 displayed with an approval field and an authorization field. 
The approval and authorization fields are modifiable by the 
first and second users respectively where the first user has 
payment approval privileges and the second user has payment 
authorization privileges. In a non-limiting example, a field 

20 is provided allowing the second user to provide payment 
remittance information including credit card information, an 
authorization to debit a bank account, wire transfer 
information, direct deposit information or an indication 
that a check will be mailed. 

25 

In accordance with another broad aspect, the invention 
provides a computer readable medium including a program 
element executable by a computing apparatus for implementing 
the above described method. 

30 

In accordance with a broad aspect, the invention 
provides a system implementing the above-described method. 



7 



In accordance with another aspect, the invention 
provides a method for granting payment of an invoice over a 
network, the invoice having been issued by a biller entity 
5 to a customer entity. The method includes transmitting over 
the network to the biller entity an approval status data 
element associated to the invoice from a first user 
associated to the customer entity. The method also includes 
transmitting over the network to the biller entity an 

10 authorization status data element associated to the invoice 
from a second user associated to the customer entity. 
Payment of the invoice is granted by the customer entity if 
the approval status data element indicates that the invoice 
has been approved and the authorization status data element 

15 indicates that the invoice has been authorized. 

In a specific implementation, the first user has 
payment approval privileges, the payment approval privileges 
being assigned by the customer entity. The second user is 
20 distinct from the first user and has payment authorization 
privileges, the payment authorization privileges being 
assigned by the customer entity. 

In accordance with another aspect, the invention 
25 provides a method for handling an invoice over a network, 
the invoice having been issued by a biller entity to a 
customer entity. An approval status data element associated 
to the invoice is received over the network at a biller 
entity. An authorization status data element associated to 
30 the invoice is received over the network at a biller entity. 
The biller detects the granting of payment of the invoice if 
the approval status data element indicates that the invoice 
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has been approved and the authorization status data element 
indicates that the invoice has been authorized. 

In a non-limiting example, payment of the invoice is 
5 expected at the biller entity when the granting of payment 
of the invoice has been detected. 

In a specific implementation, the approval data element 
is associated to a first user. The approval status data 

10 element and an identifier associated with the first user are 
processed to determine if the first user has payment 
approval privileges. The detection of the granting of 
payment is prevented if the first user does not have payment 
approval privileges. Similarly, the authorization status 

15 data element is associated to a second user. The 
authorization status data element and an identifier 
associated with the second user are processed to determine 
if the second user has payment authorization privileges. 
The detection of the granting of payment is prevented if the 

20 second user does not have payment authorization privileges. 

In accordance with a broad aspect, the invention 
provides a computer readable medium including a program 
element executable by a computing apparatus for implementing 
25 the above described method. 

In accordance with a broad aspect, the invention 
provides a method for electronically presenting and granting 
payment of invoices. An invoice is generated at a biller 
30 and making the invoice electronically available to a 
customer entity. A plurality of users associated to the 
customer entity are enabled to complete respective stages of 
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a multi-stage invoice handling process and transmit data 
elements indicative that the respective invoices processing 
stages have been completed. Granting of payment of the 
invoice is detected at the biller when the data elements 
5 indicative that respective invoice processing stages have 
been completed are received at the biller. 

In a non-limiting example of implementation, the multi- 
stage invoice handling process includes a first stage and a 
10 second stage. A first user is enabled to complete the first 
stage and a second user is enabled to complete the second 
stage subsequent the data element indicating that the first 
has been completed is received at the biller. 

15 Advantageously, this allows the stages of the invoice 

handling process to be effected in a desired order. 

Other aspects and features of the present invention 
will become apparent to those ordinarily skilled in the art 
20 upon review of the following description of specific 
embodiments of the invention in conjunction with the 
accompanying figures. 

Brief Description of the Drawings 

25 

Fig. 1 is a block diagram of an electronic invoice 
presentment and payment remittance system in accordance with 
an embodiment of the invention, including a biller computing 
system 116, a network 106, and a customer computing system 
30 150 having a plurality of computing units; 
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Fig. 2a is a block diagram depicting one of the 
customer computing units shown in figure 1 in accordance 
with an embodiment of the invention; 

5 Fig. 2b is a block diagram depicting the biller 

computing system 116 shown in figure 1 in accordance with an 
embodiment of the invention; 

Figure 3 is a flow diagram of a registration phase for 
10 use in connection with a process for electronically 
presenting and granting payment of invoices in accordance 
with an example of implementation of the invention; 

Fig. 4 is a flow diagram of the process for 
jfft 15 electronically presenting and granting payment of invoices 
O in accordance with a specific example of implementation of 

)Ul the invention; 

Fig. 5a and 5b is a non-limiting example of 
20 implementation of a graphical user interface for presenting 
a plurality of unpaid invoices associated to a customer 
entity. 

In the drawings, embodiments of the invention are 
25 illustrated by way of example. It is to be expressly 
understood that the description and drawings are only for 
purposes of illustration and as an aid to understanding, and 
are not intended to be a definition of the limits of the 
invention. 

30 

Detailed Description 

I 
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The method and system for processing invoices provide 
multi-stage invoice handling capabilities. The multi-stage 
invoice handling process allows different users associated 
5 to a customer entity to be given different responsibilities 
in the handling of an invoice. In the example described, 
the multi-stage invoice handling process includes two 
stages, namely an approval stage wherein an invoice is 
approved for payment by a person permitted to do so, 
10 followed by an authorization stage wherein the actual 
payment is authorized to be made under the authority of a 
second person permitted to do so. It will be appreciated 
that a multi-stage invoice handling process having in excess 
of two stages remains within the scope of the invention. 

15 

Fig. 1 shows an electronic invoice presentment and 
payment remittance system 100 in accordance with a specific 
implementation. The system 100 allows a customer entity 102 
to view the state of its accounts payable with regards to a 

20 specific biller 104 and to issue payment instructions to 
that specific biller 104. The system 100 also allows the 
specific biller 104 to receive information regarding the 
payment stage of a certain invoice. The system 100 includes 
a biller computing system 116 and a customer computing 

25 system 150 interconnected through a network 106. The biller 
computing system 116 and the customer computing system 150 
include tools for facilitating online commerce transactions 
between the customer entity 102 and the biller entity 104. 

30 The network 106 is a data communication network 

interconnecting the customer computing system 150 and the 
biller computing system 116. In a specific example of 
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implementation, the network is a public network. In the 
illustrated implementation, the data communication network 
106 is embodied in the Internet. It is to be noted that the 
data communication network 106 may be implemented as a 
5 network other that the Internet such as an interactive 
television (ITV) network, a private network such as an 
Intranet or any other suitable network. 

The customer computing system 150 comprises a plurality 

10 of computing units 112 114, each associated to a respective 
user 108, 110. The computing units 112 114 are generally in 
the form of personal computers, although other types of 
computing units may be used including laptops, notebooks, 
hand-held computers, set top boxes, and the likes. The 

15 plurality of computing units 112 114 may be connected to one 
another over an Intranet or may be stand-alone computing 
units. Each of the computing units 112 114 is provided with 
a connection to the network 106. The connection may be a 
permanent connection through a server at the customer's 

20 premises, or alternatively, a given computing unit may 
occasionally connect to the network 106 through the use of a 
dial-up connection using suitable devices such as a modem 
for example. For the purpose of simplicity, the example 
described herein below considers a customer computing system 

25 150 including two customer computing units 112 114 each 
being respectively associated to a first user 108 and a 
second user 110. It will be readily appreciated that a 
customer computing system 150 including in excess of two 
customer-computing units remains within the invention. 

30 

Figure 2a depicts a block diagram of customer computing 
unit 112. The structure and functionality of customer 
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computing unit 114 is identical to that of customer 
computing unit 112 and as such will not be described. As 
shown, the customer computing unit 112 comprises a processor 
210, a memory 220 and a network I/O 224 ( input /output ) for 
5 accessing the network 106. The network I/O 224 can be 
implemented, for example, as a dial-up modem or as a 
permanent network connection. The processor 210 is adapted 
to execute program elements stored in the memory 220 for 
performing certain functions. More specifically, the 

10 customer computing unit 112 runs an operating system 218 
that supports multiple applications. The operating system 
218 is preferably a multitasking operating system that 
allows simultaneous execution of multiple applications in a 
graphical windowing environment. The memory 22 0 also 

15 includes a browser program element 222. The browser program 
element 222 when launched is executed by the processor 210 
atop the operating system 218. The customer computer unit 
112 may also include e-mail software components (not shown) 
as well as additional components and modules. These have 

20 been omitted from the description for the purpose of 
clarity . 

The biller computing system 116 includes one or more 
computer servers and one or more computing apparatuses. The 

25 system includes program elements allowing the biller entity 
104 to manage customer invoices and to provide electronic 
processing of invoices. The biller computing system 116 may 
also include modules for connection to a payment network 152 
(shown in Figure 1) . The payment network 152 represents 

30 existing networks that presently accommodate transactions 
for credit cards, debit cards, checks and other types of 
financial payment processes. A description of the payment 
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network 152 and of the interaction of the biller computing 
system 116 with the payment network 152 is not necessary for 
the understanding of the present invention and as such will 
not be described. 

5 

Figure 2b shows a block diagram depicting a schematic 
diagram of the biller computing system 116. As depicted, 
the biller computing system 116 comprises a processor 208, a 
memory 200 and a network I/O 226 (input /output ) for 

10 connection to the network 106. The network I/O 226 is 
preferably implemented as a permanent network connection 
although dial up connections may be suitable in certain 
embodiments. For example, if the biller computing system 
116 interacts with the customer computing system 150 via e- 

15 mail, then a dial-up connection may be suitable. 

The processor 208 is adapted to execute program 
elements 204 stored in the memory 200 for performing various 
functions. The memory 200 also has a data portion 20 6 
20 including a customer database 202 and an invoice database 
203. It will be readily appreciated that the biller 
computing system 116 may include additional components and 
modules. These have been omitted from the description for 
the purpose of clarity. 

25 

The customer database 202 includes information 
pertaining to the customers of the biller entity. In a non- 
limiting implementation, for each customer entity, an entry 
is provided including various information data elements 
30 associated to the customer entity. Amongst others, each 
entry includes a plurality of records, each record including 
a user identifier with a corresponding password. In 



15 



addition, each user identifier is associated to respective 
privileges defining stages which the user is permitted to 
complete. In a specific example, the customer database 
includes a first user having payment approval privileges and 
5 a second user having payment authorization privileges. The 
table below is a representation of an entry in the customer 
database for customer ABC INC. As shown, ABC INC. has five 
records for users (Userl, User2, User3, User4, User5). 
Userl and User4 have payment approval privileges and User2 
10 has payment authorization privileges. User3 has neither 
payment approval nor payment authorization privileges. 
User5 has both payment approval and payment authorization 
privileges . 



Customer ABC Inc. : User list 


User name 


Password 


Privileges 


Userl 


1234 


Approval: Yes 
Authorization: No 


User2 


9876 


Approval: No 
Authorization: Yes 


User3 


7656 


Approval : No 
Authorization: No 


Dser4 


5656 


Approval: Yes 
Authorization: No 


UserS 


4321 


Approval: Yes 
Authorization: Yes 



As a variant, invoices issued by the biller are 
assigned to different categories. For example, the 

categories may be based on the type of product /service 
offered by the biller or on the amounts of the invoice 
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amongst others. In this variant, each user identifier is 
associated to respective privileges defining stages which 
the user is permitted to complete for an invoice in a given 
category. The table below is a representation of an entry 
5 in the customer database for customer DEF INC. providing 
user privileges on the basis of category. As shown, DEF INC. 
has two records for users (Userl, User2) . Userl has payment 
approval privileges for invoices in the category animal 
stock only. User2 has payment approval privileges for 
10 invoices in the commodities category, the luxury items 
category and the animal stock category. User2 has payment 
authorization privileges for invoices in the luxury items 
category and the animal stock category. 



Customer DEF Inc. : User list 


User name 


Password 


Category 


Privileges 


Userl 


3434 


Commodities 


Approval : No 
Authorization: No 


Luxury items 


Approval: No 
Authorization: No 


Animal Stock 


Approval: Yes 
Authorization: No 


User2 


2357 


Commodities 


Approval: Yes 
Authorization: No 


Luxury items 


Approval: Yes 
Authorization: Yes 


Animal Stock 


Approval: Yes 
Authorization: Yes 
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As another variant, the system provides a plurality of 
levels of permission. For example, regarding approval 
privileges, a first user at the customer site is permitted 
to approve invoices of up to a first amount limit; a second 
5 person is permitted to approve invoices of up a second 
amount limit, the second amount limit being higher that the 
first amount limit; a third person is permitted to approve 
invoices of up a third amount limit, the third amount limit 
being greater that the second amount limit; and so on. 

10 Similarly, a plurality of levels of permissions may be 
provided for the other stages of the invoice handling 
process. The number of levels of permissions may vary from 
one customer to the other without detracting on the spirit 
of the invention and will generally be determined on the 

15 basis of the organizational style of the customer entity. 
Advantageously, the use of a plurality of levels of 
permissions allows the invoice presentment and payment 
remittance system to be better suited to large business 
environments. More specifically, it is common in large 

20 business environments to delegate to senior administrators 
the responsibility of approving invoices for small expenses 
such as paper supplies for example. Larger expenses however 
generally require the authorization of a director or vice 
president in a business. This feature permits the two 

25 systems to be integrated such as automatically differentiate 
between the two levels of permissions. 

It is to be expressly understood that other formats for 
a customer database 202 are possible without detracting from 
30 the spirit of the invention. 
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The user identifiers and the privileges associated to 
each are provided by the customer entity 102 to the biller 
104 via a registration process. 

The invoice database 203 includes for each customer in 
5 the customer database 202 a list of invoice entries 
associated to invoices that are not fully paid. Each 
invoice entry includes an invoice identifier, an invoice 
amount, an unpaid amount and a plurality of status data 
elements defining the processing stage of the invoice. 

10 Other data elements may also be present without detracting 
from the spirit of the invention. In a non-limiting example 
of implementation, a given invoice is associated to an 
approval status data element and an authorization status 
data element. The authorization status data element is 

15 indicative of either one of payment authorization and 
absence of payment authorization by the customer entity. 
The approval status data element is indicative of either one 
of payment approval and absence of payment approval by the 
customer entity. As a variant, the approval status data 

20 element is associated to an amount data element indicative 
of an amount of the invoice which has been approved for 
payment . 

The memory also includes a program element 204 for 
25 operating on the data 206 for managing a customer's account 
as well as tools to allow the biller 104 to manage customer 
invoices in the invoice database 203 and to provide 
electronic handling of invoice. 

30 A typical interaction will better illustrate the 

functioning of the electronic invoice presentment and 
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payment remittance system 100 and of the program elements 
204 . 

Prior to the use of the electronic invoice presentment 
5 and payment remittance system 100 , the customer entity 102 
registers with the biller entity 104. The registration 
between the customer entity and the biller entity may be 
effected over the network 106 or by providing a form to be 
transmitted by mail, fax or other suitable transmission 

10 methods. Registration over the network 106 through a web- 
based interface will be described herein below with 
reference to Figure 3 of the drawings. Registration through 
the other methods will be readily apparent to the reader 
skilled in the art. At step 300, a user at the customer site 

15 accesses a designated registration website associated with 
the biller through a network link by providing a network 
address. This action submits a request for registration of a 
new customer with the biller entity 104. In response, the 
customer entity system downloads a registration module 

20 implemented by program element 204 (shown in figure 2) from 
the biller computing system 116 to a customer computing 
unit. The registration module automatically launches to aid 
the user at the customer site in the completion of the 
online application for registration. In a specific example 

25 of implementation, the registration module is configured to 
provide step-by-step instructions. At step 302, the user at 
the customer site fills out a form including various fields 
related to personal and financial matters, such as company 
name, address, telephone number, credit card numbers, bank 

30 affiliations, and the likes. The user also provides data 
related to preferred payment methods, a list of authorized 
user identifiers and passwords as well as the privileges 
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associated to each user identifier. Some of these 
information fields may be omitted and others added without 
detracting from the spirit of the invention. At this stage, 
the user can enable a first user associated to a user 
5 identifier to approve invoices and a second user associated 
to a user identifier to authorize invoices. In order to 
increase security, the user requesting registration at the 
customer site provides an indication that he (she) is 
permitted to register the customer with the biller. This 

10 may be effected by providing a pre-arranged password at the 
time of registration, by providing a signed document 
attesting to this, or by some other means. Once the 
application for registration is completed at step 303, the 
application for registration is submitted to the biller 

15 entity 104. The registration module facilitates this 
communication between the customer entity 102 and the biller 
entity 104. The application form itself, or the registration 
module, contains the necessary routing information to direct 
the application over the network 106 to the biller computing 

20 system 116. At step 308, the biller entity 104 reviews the 
application for registration to determine whether the 
customer entity 102 should be permitted to register and 
whether any information is missing. If registration is 
denied, for example information is missing, the customer 

25 entity is already registered or the user requesting 
registration does not have the permission to do so, at step 
312 the biller entity 104 returns a message to the customer 
entity 102 indicating that the application for registration 
has been denied. Conversely, if the application is granted, 

30 the biller entity 104 may return a message indicating that 
the application for registration is successful. 
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Assuming that the application for registration is 
granted, at step 310 the biller computing system 116 at the 
biller entity 104 creates a customer account entry in the 
customer database 202 including a customer identifier and a 
5 plurality of records. Each record associated to the 
customer identifier includes an authorized user name, 
password and associated privileges. In a specific 

implementation, the customer entity entry in the customer 
database includes at least one record where a first user is 

10 associated with payment approval privileges and a second 
record where a second user is associated with payment 
authorization privileges. A link between the customer 
account entry in the customer database 202 is associated to 
an entry in the invoice database 203. In a specific 

15 implementation, the program element further provides 
functionality for allowing a user at the consumer entity to 
modify the entries in the consumer database such as to 
add/remove authorized user identifiers, modify passwords, 
modify privileges and so on. Following this, the registered 

20 customer may handle invoices over the network 10 6. 

Figures 4 is a flow diagram of a process for 
.electronically presenting and granting payment of invoices 
in accordance with specific examples of implementation of 
25 the invention. 

With reference to figure 4, at step 400, the biller 
computing system 116 generates an invoice at the biller 
entity. The invoice is stored in the invoice database 203 
30 and is association with a customer account entry in the 
customer database 202. The status data elements defining the 
processing stage of the invoice are also set at this stage. 
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In a non-limiting example, the authorization status data 
element is indicative of an absence of payment authorization 
and the approval status data element is indicative of an 
absence of payment approval. 

5 

At step 402, the invoice is made electronically 
available to the customer entity. In a first non-limiting 
example of implementation, the invoice is transmitted via e- 
mail to the first and second users at the customer entity. 

10 In this implementation, the invoice is provided as a data 
structure including an approval field and an authorization 
field, the approval and authorization fields being 
modifiable by the first and second users respectively. In a 
non-limiting example, a field is provided allowing the 

15 second user to provide payment remittance information credit 
card information, an authorization to debit a bank account, 
wire transfer information, direct deposit information or an 
indication that a check will be mailed. 

20 In a second non-limiting example of implementation, the 

invoice is made electronically available over network 106 by 
providing a designated website. In a non-limiting example, 
the website is a secure website implementing an electronic 
invoice payment system. Authorized users associated with the 

25 customer entity can access the site in order to perform 
designated tasks. 

In a second specific example of implementation, the 
invoice is electronically transmitted over the Internet. In 
30 a non-limiting example of implementation, in order to view 
invoices and other account information, the users associated 
with the customer entity log on to a secure web-site using 
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login names and associated passwords. The account 
information is displayed on a graphical user interface on 
the customer's computer terminal. Each unpaid invoice is 
displayed with an approval field and an authorization field. 
5 The approval and authorization fields are modifiable by the 
first and second users respectively where the first user has 
payment approval privileges and the second user has payment 
authorization privileges. In a non-limiting example, a field 
is provided allowing the second user to provide payment 
10 remittance information including credit card information, an 
authorization to debit a bank account, wire transfer 
information, direct deposit information or an indication 
that a check will be mailed. 

15 In a typical interaction, users associated to the 

customer entity access a designated website through a 
network link by providing a network address in order to view 
invoices and other account information. The users log on to 
the secure website by providing login information including 

20 a customer identifier, a login name and a password. The 
biller computing system received the login information and 
processes it with respect to the customer database 202. 
More specifically, the processor 208 accesses the customer 
database 202 to locate the entry corresponding to the 

25 customer identifier. If no corresponding entry is found, an 
error message is returned to the customer entity. If a 
corresponding entry is found, the processor 208 attempts to 
locate a record corresponding to the login name provided. If 
no corresponding record is found, an error message is 

30 returned to the user. If a corresponding record is found, 
the password in the record is compared to the password 
provided in the login information. If a match is not found, 
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an error message is returned to the user. If a match is 
found, the user is successfully identified. 

Once a user is successfully identified, the account 
5 information in the invoice database 203 corresponding to the 
customer identifier is transmitted to the user's terminal 
for display on a graphical user interface at the user' s 
computer terminal. The graphical user interface provides 
the user with the ability to view one or more outstanding 
- 10 invoices associated with the biller entity 104. Figures 5a 
and 5b of the drawings depicts a graphical user interface 
showing 3 unpaid invoices in a table 504. Each invoice is 
depicted as a row 506 in the table 504, each invoice being 
associated to various information data elements describing 
_ 15 characteristics of the invoice. In a non-limiting example, 
the graphical user interface provides a link for accessing 
an electronic copy of the complete invoice. In the 

graphical user interface shown in Figures 5a and 5b, this is 
effected by providing a link associated to the invoice 

20 number in the invoice number column 508. When activating a 
link in the invoice number column 508, a corresponding 
invoice is displayed to the user at the customer entity 
site. In a non-limiting implementation, each invoice is 
provided with a selection column 500 allowing the user to 

25 approve or to authorize payment of an invoice by checking a 
box . 

Continuing the typical interaction, at step 404, a 
first user accesses the designated website in the manner 
30 described above, where the first user has payment approval 
privileges in the customer database but does not have 
payment authorization privileges. Once the first user has 
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viewed a certain invoice there is the choice of approving 
the invoice for payment or authorizing the payment to take 
place or to do none of the above. 

5 In a first embodiment, the first user enters in the 

selection column 500 instructions to approve the invoice by 
checking a box or filling in a field. At step 408, the 
instructions are sent to the biller entity over the network 
106. The biller entity processes the instructions received 

10 from the first user. More specifically, the biller system 
determines whether the first user was associated to the 
appropriate permissions in the customer database 202 to be 
permitted to issue the instructions. For example, if the 
first user checks the box associated to payment 

15 authorization, the biller system will check in the customer 
database if the first user has payment authorization 
privileges. Since the first user has payment approval 
privileges but does not have payment authorization 
privileges, the biller system will return an error message 

20 to the first user indicating that the instructions are being 
disregarded. If the first user checks the box associated to 
payment approval, the biller system will check in the 
customer database if the first user has payment approval 
privileges. Since the first user has payment approval 

25 privileges, the biller system will mark the invoice in the 
invoice database as being approved. 

In a second embodiment, the graphical user interface is 
conditioned on the basis of the privileges associated to the 
30 user. For example, if the user accessing the system has 
payment approval privileges, then only the field (s) 
associated to the approval of the invoice is (are) active 
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with the other fields being deactivated or alternatively 
being completely absent. The first user enters in the 

selection column 500 instructions to approve an invoice by 
checking a box. At step 408, the instructions are sent to 
5 the biller entity over the network 106. The biller entity 
processes the instructions received from the first user. In 
this embodiment, the biller entity processes the 
instructions received from the first user to modify the 
status data element associated to the invoice in the invoice 
10 database accordingly. However, since only the boxes 

associated to permitted actions are active, the biller 
system, upon receipt of an instruction, does not need to 
check if the first user was permitted to issue payment 
approval if this invoice. 

15 

Continuing the typical interaction, at step 406, a 
second user accesses the designated website in the manner 
described above, where the second user has payment 
authorization privileges in the customer database but does 

20 not have payment approval privileges. It is to be noted 
that in this specific example of implementation, the second 
user can access the designated website prior to, 
simultaneously with or subsequent to the first user. For 
each invoice, the second user is presented with the fields 

25 for approving the invoice for payment, authorizing the 
payment to take place or to do none of the above. 

In a variant, the second user associated to the 
customer entity is enabled to authorize payment of the 
30 invoice when the second user is associated to authorization 
privileges and the approval status data element is 
indicative of payment approval. Accordingly, in this 
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specific variant, the second user is enabled to authorize 
payment of the invoice subsequent the data element 
transmitted by the first user and indicating that payment of 
the invoice has been approved is received at the biller. 

5 

In the first embodiment, the second user enters in the 
selection column 500 instructions to approve or to authorize 
payment of an invoice by checking a box. At step 410, the 
instructions are then sent to the biller entity over the 

10 network 106. The biller entity processes the instructions 
received from the second user. More specifically, the 
biller system determines whether the second user was 
associated to the appropriate permissions in the customer 
database 202 to issue the instructions in a similar fashion 

15 as that described in connection with the first user. If the 
second user checks the box associated to payment 
authorization, the biller system will modify the status data 
element associated to the invoice in the invoice database 
accordingly. 

20 

In a second embodiment, the graphical user interface is 
conditioned on the basis of the privileges associated to the 
user. The second user enters in the selection column 500 
instructions to authorize an invoice by checking a box. At 

25 step 410, the instructions are sent to the biller entity 
over the network 106. The biller entity processes the 
instructions received from the second user. In this 
embodiment, the biller entity processes the instructions 
received from the second user to modify the status data 

30 element associated to the invoice in the invoice database 
accordingly. However, since only the boxes associated to 
permitted actions are active, the biller system, upon 
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receipt of an instruction, does not need to check if the 
second user was permitted to issue payment authorization of 
the invoice. 

5 In a non-limiting example of implementation, subsequent 

to the second user issuing a payment authorization 
instruction, a payment module automatically launches to aid 
the second user in the completion of the online payment 
authorization stage 414. In a specific example of 

10 implementation, the payment module is configured to provide 
step-by-step instructions. The second user fills out a form 
including various fields related to payment instructions. 
The authorization stage may include providing the biller 
with a credit card number, with an authorization to debit a 

15 bank account, wire transfer information, direct deposit 
information or simply an indication that the check will be 
mailed on a certain day. The information regarding the 
payment instructions is submitted to the biller entity over 
the network 106. The biller entity receives the payment 

20 instructions. Alternatively, default payment instructions 
may be provided by the customer at the time of registration 
or subsequently indicate a default manner of paying 
invoices. In this alternative, step 414 may be omitted. 

25 At step 411, the biller computing unit verifies if an 

invoice in the invoice database has been both approved and 
authorized. In the affirmative, the biller computing system 
116 processes or waits for payment of the invoice in a 
conventional manner on the basis of the payment instructions 

30 provided by the customer. 
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Although the detailed description describes extensively 
a system for electronically presenting and granting payment 
of invoices where the invoices are accessible via a web 
based interface, other embodiments are possible. For 
5 example, invoices may be sent to first and second users at 
the customer entity via electronic mail, the first user 
having payment approval privileges and the second user 
having payment authorization privileges. At the customer 
site, the first and second users open the received 

10 electronic mail and the account information contained 
therein is displayed on a graphical user interface on the 
users' computer terminals. The processing of the invoice 
at the biller site may be effected in a similar fashion as 
that described above. In the case of the transmission of an 

15 invoice by e-mail, having a graphical user interface 
conditioned on the basis of the privileges associated to the 
users to whom the e-mail is sent will result in fewer e-mail 
transmissions between the customer entity and the biller. 

20 Although the present invention has been described in 

considerable detail with reference to certain preferred 
embodiments thereof, variations and refinements are possible 
without departing from the spirit of the invention. 
Therefore, only the appended claims and their equivalents 

25 should limit the scope of the invention. 



